1. Field of the Invention
The present invention relates to an evaluation apparatus and method, and in particular to an apparatus and method for monitoring and controlling a device under test, for example an electronic device.
2. Description of the Related Art
Manufacturers of electronic devices often provide evaluation tools for use by their engineers and their customers. These tools enable engineers to monitor and control an electronic device during a system design. When testing and evaluating electronic devices in this way, engineers require the ability to change various settings on a Device Under Test (DUT). Engineers may also need to retrieve and monitor the current settings.
There are a number of different scenarios where this is required. FIG. 1 shows an example of a first scenario in which a DUT 1 is placed on an evaluation board 3 and controlled using a separate computer 5. The evaluation board 3 has appropriate supporting circuitry and components that allow the operation and performance of the DUT 1 to be evaluated. In this scenario control software running on the computer 5 communicates with the DUT 1 via a communications link 7 (for example a USB, serial or parallel communications link). In practice some form of additional interface is also provided, for converting signals received from the computer 5 into signals that the DUT 1 can process. Typical communication interfaces for devices under test include AC'97, I2C, I2S or SPI. This scenario is typically used during the initial evaluation of a DUT 1 (and also during development) to debug problems and work out how to achieve the best operation and performance from the DUT 1.
FIG. 2 shows a second scenario in which the DUT 1 is installed on some form of development platform 9 that also includes all the processor(s), memory, controllers and other components and devices necessary to develop a full system. In this case the control software is running on the development platform and communicating with the DUT directly via one or more interfaces, (for example AC'97, I2C, I2S or SPI as mentioned in the first scenario). This type of arrangement is typically used during system development in order to help get a whole system up and running, including all of the hardware, software and drivers necessary for full development. The development platform 9 is also used for debugging problems that occur when integrating the different components of the system. Once fully debugged and working, the development platform 9 will typically be used as a reference platform for one or more customer applications (i.e. mass-market products).
According to a third scenario shown in FIG. 3 the DUT 1 is installed in a customer application 11 that also includes all the processor(s), memory, controllers and other components and devices necessary for a full system. In this case the control software is running on the customer application and communicating with the DUT directly via one or more appropriate interfaces (for example AC'97, I2C, I2S or SPI as mentioned above). This scenario is typically used by a customer once a customer's application has been developed from a reference design, for debugging integration issues which occur during the development of the application.
The devices under test are controlled using registers which have an n-bit address (typically 6, 7 or 8 bits) and an n-bit data value (typically 8, 9 or 16 bits). The data values consist of one or more data fields, each data field comprising one or more data bits for controlling various aspects of the DUT. The data values may also comprise one or more null bits which have no effect on the DUT.
FIG. 4 illustrates an example of a register map having ten control registers R0-R9 plus a reset register R15. These registers comprise an address portion having seven address bits B9-B15 and a data portion comprising nine data bits B0-B8:
The first register R0 is shown as having three data fields: a 5-bit-wide field called “LINVOL” (from data bits B4 to B0) and 2 single-bit fields called “LIN MUTE” (data bit B7) and “LRIN BOTH” (data bit B8). The first register R0 also has 2 null bits corresponding to bits B5 and B6.
As will be appreciated by a person skilled in the art, a register must always be written completely. In other words, it is not possible to update only certain data fields or bits within the register. This means that, if only one data field or data bit of the register is to be changed, the remainder of the register must also be rewritten with its current value. For example, if the status of the data field “LIN MUTE” at data bit B7 of the first register R0 requires changing, for example by writing a “0” to data bit B7, while leaving the other data bits at their current values, then the only way to achieve this is to ascertain the current values for each of the other data bits in register R0, reset data bit B7 (i.e. set B7 to 0) and write the adjusted data value back to the register R0.
Some devices support a read-back of a current value in a register, thus allowing an engineer to read the current value, make the modifications required and write the updated value back again with confidence. This is known as a “read-modify-write” operation.
However, other devices only support writing to the registers. Such systems require engineers to remember or store the last-written value for each register, so that this value is ready for use when making subsequent updates. Since the last-written value is stored on the host CPU (or “cached”), a situation can arise where the device under test holds a register value which is different to that stored in the cache, for example if another application has written to the device independently, or if the device has been reset to default values without also resetting the cached values. Such cached values are therefore less trustworthy than values which have been read directly from the device.
Furthermore, on devices which support read-back, some values are read-only and cannot be modified by the software running on the host CPU. Typically, these are status fields or the results of analogue-to-digital conversions monitoring external voltage levels (e.g. battery voltage level). Some devices have registers in which the data fields exhibit a mixture of access types—read-only, write-only and read-write.
Registers which contain a mixture of write-only and read-write fields are particularly difficult to handle. To make a change to the settings held in such a register, the engineer must remember the value they last wrote to the device for the write-only bits, combine it with the value read from the device for the readable bits, make the desired changes, then write the new value back to the device register. For example, consider a device register where the whole 16 data bits control various aspects of the device, but only data bits 15-8 can be read back. Also, assume that the last value written to the register was 0x4372, and that the data field at bits 15-12 can be updated by the device and now holds value 0x5. If an engineer wishes to set data bit 7, then the engineer has to perform the following steps for updating the partially readable register:
ActionValueRead the current value from the register0x5300Retrieve the stored last write value0x4372Mask off the readable bits0x0072Combine the two values to obtain the real current value0x5372Set bit 7 (0x0080)0x53F2Write the new value to the register0x53F2
As will be appreciated from the above, a user has to monitor several aspects when controlling registers in a device under test. Therefore, when making changes to register values, it would be desirable to know how data bits correspond to data fields, which data fields can be modified and which can be trusted. Also, when performing debugging operations, it is particularly important to be aware of which settings have been read from the device and can be trusted, and which settings have come from a cache and hence may be incorrect. It is also useful to know what settings have been changed from the default start-up configuration of the device, as this information can be used to narrow down the area where problems are likely to exist. In addition, when developing control software sequences, an engineer needs to know what settings have been written so the setting can be duplicated in their software sequence.
FIG. 5 shows a known evaluation tool 51 for assisting engineers when monitoring and controlling a device under test. The evaluation tool 51 comprises a panel of controls, which allow the settings of the device under test to be controlled in a reasonably intuitive manner. For example, control element 53 allows the “LEFT MUTE” setting to be controlled, control element 55 allows the power-down settings to be controlled, and so on.
Although such a system has the benefit of making the settings easy for the engineer to interpret and update, the panel of controls does not convey how the various settings relate to the actual register values. As a result, it is difficult to set up the panel to match a set of register settings from a failing system. Furthermore, there is no way of determining which settings are inter-dependent, i.e. need to be written simultaneously because they are located in the same register.
Other disadvantages of this type of system include not being able to determine whether changes made to settings through the panel have actually been submitted to the device. In other words, although it becomes clear when a control element such as “LEFT MUTE” 53 has been changed on the control panel, this does not confirm if the updated setting of “LEFT MUTE” has been submitted to the device under test. This system also has the disadvantages of not being able to identify default settings (hence being unable to identify what has changed), and not being able to retrieve current settings for use in control software. Furthermore, an engineer can easily forget that the current settings may not reflect those of the device (e.g. because the device is write-only). The software for complex devices also needs to be organised into multiple control panels, thus preventing a quick overview of the state of the whole device under test.
FIG. 6 shows another known evaluation tool, which allows a register to be specified and then either written or read. The control panel 61 comprises a register index 63, which presents the register value as both checkboxes 65 corresponding to individual data bits of the register, and the complete register value 67. Although this system allows all data bits in a register to be controlled individually, there is no indication of what register data bits mean and how they relate to data fields. Furthermore, it is only possible to work on one register at a time, and there is no indication of whether the register value matches the device. In addition, it is not possible to determine default settings, and hence what has been changed.
Other types of evaluation tools are also known for providing alternative methods of allowing an engineer to monitor and control register values in a device under test. However, these tools all suffer from the disadvantages of being unable to relate device settings to register values, and being unable to determine which settings are inter-dependent (thus requiring simultaneous writing because they are located in the same register).
It is an aim of the present invention is to provide an apparatus and method of monitoring and controlling a device under test, which does not suffer from the disadvantages mentioned above.